因為結構設計的關係，會有一篇是類似一章的開始，後面才會開始細談，為了避免被讀者認為打水，以及擔心剩下的天數講不完，於是今天會一次談及兩個標題的內容。

如何現形開發流動？

前面聊到何謂流動，以及現形的概念。接下來幾篇就會依序針對流動順暢度、開發流程、與生命週期去探討如何現形，以及如何善用工具在工作場域現形的經驗與實踐，並在最後的總結中談及現形了開發流動後，可以怎麼利用這個這樣基礎，持續改善開發流動。

其中在工具中，專案管理工具至少會以 Jira 為例，時間允許的部分會擴充 Azue DevOps 的部分。也會在部分章節中搭配 Miro 與 Google Sheet 等工具。

大致會是這樣的結構：

• 如何現形開發流動？
  • 如何現形流動順暢度？
  • 如何善用工具在工作場域現形流動順暢度？
  • 如何現形開發流程？
  • 如何善用工具在工作場域現形開發流程？
  • 如何現形需求生命週期？
  • 如何善用工具在工作場域現形需求生命週期？
• 現形了開發流動，然後呢？
• 如何現形開發流動？

如何現形流動順暢度？

流動順暢度我想應該是在三個面向中，最為抽象而難以現形的。不像需求生命週期，可以透過圖像、視覺看板，甚至時間軸去呈現；開發流程可以透過互動圖、政策、方針、指南的說明去理解、甚至是 pipeline 的形式呈現；流動順暢度就顯得無形許多，又該如何將其現形？

前面聊到何謂開發流動時，有提及可以透過現實中道路與車輛的比喻去聯想，有一些情況是可以藉此了解當前流動是否順暢的：

• 單位時間交付的載貨量
• 單位時間聽過的車輛數
• 同一路段的車輛數（擁擠程度）
• 這段路程所耗費的時間
• 這段路程停滯的時間
• 路程效率——行滯比（車輛行駛的時間占全程時間的百分比）

看這這些比喻，會不會讓你想起你已經在用的實踐呢？能夠一一連結起來嗎？這就是我們接下來會來聊聊的一些現形方式，包括但不限於：

• 順暢度的表徵 —— Velocity
• 更中立的指標 —— Lead Time 與他的小夥伴
• 塞車的偵測器 —— CFD
• 不一樣的速率 —— Throughput

但不管現實中的比喻，或留軟體開發常用的方式，相比需求生命週期與開發流程，有一個共同點——多是會用到指標。而指標也就代表量化、科學、讓人信服等正面印象，但這也同時是在現形流動順暢度時，容易遇到的困境——數據記錄的不易，以及容易過早下定論。

從無形到現形的困境

要讓流動順暢度，從無形到現形的過程中，首先就是要有指標，再將指標繪製成圖表以作為更直觀的呈現。這中間的歷程也就是抽象到數據、數據到指標、指標到圖表。而萬事起頭難，首先就是要開始積累數據，然而該如何持之以恆地去搜集數據以計算出指標，就會是這個議題所遇到的困境。

很少有程式設計師是願意將自己的時間放在開發軟體以外的事情，說動這些夥伴運行敏捷開發，更多擁抱產品已實屬不易，還要他們乖乖的、嚴謹的紀錄一些他們不一定直觀感受到好處的數據？（苦笑）

這時候就是善用工具或是一些互動方式協助的時候了，這部分我會在後面好好詳述。讀者也可以思考遇到這樣的困境，你有什麼想法，不妨先寫在紙上或留言區做個交流。

指標是判讀、還是判決？

好不容易產出指標時，卻也容易在這時踩進了另一個陷阱——直接看指標就作出審判。最怕就是管理者或是產品負責人，看到 Velocity 的數值時，直接說出一些因果關係其實還待推敲的結論。

「你們最近怎麼 Velocity 降低了？是不在偷懶？」

「為什麼上個 Sprint 可以認領 20 點，這個 Sprint 卻只認領 10 點？」

「其他團隊都可以做到 30 點，你們怎麼都只有 10 點？」

哇，這聽下來都覺得寒毛直豎了。

也正因為流動順暢度是一個相對無形的概念，一旦有任何有形的指標與圖表可以作為參考十，很容易就被作為全貌去認定。在接下來的篇章裡，也會描述該怎麼正確的使用這些現形的方式，以及各有什麼局限，最後分享如何用系統性思考看待這些指標，避免落入了以偏概全的衝突裡。

永遠記住，指標是用來參考、協助判讀的現況，不是拿來作為判決的直接證據。指標顯示的只是症狀，接下來該做的是藉此探究冰山下面的病根，好好處理才是正確的使用方式。